Scored negative file system and method

ABSTRACT

System and method for validating a payment. The method can include obtaining a first account identifier, accessing a database containing a plurality of risk scores, each one of the plurality of risk scores being associated with one of a plurality of account identifiers, obtaining a first risk score from the plurality of risk scores, the first risk score being associated with the first account identifier, and determining an acceptance decision by comparing the first risk score against a risk threshold value.

BACKGROUND OF THE INVENTION

The present invention relates to validating payments duringtransactions. In particular, embodiments of the invention relate tovalidating check payments presented during transactions.

A traditional negative file consists of account holders (i.e.,individuals or organizations with checking accounts) that currently haveoutstanding returned checks at a retailer that is a member of the sharedcheck authorization network (“SCAN”). Whenever an account holderspresents a check to a retailer, the retailer determines whether theaccount holder has any unpaid returned checks by cross-referencing thenegative file. Many of the account holders listed in the negative file,however, unintentionally write checks with insufficient funds in theirchecking accounts. Account holders may have incomplete or inaccurateknowledge concerning the balance in their account or may have forgottento transfer or deposit money to cover recent checks. Many of the accountholders listed in the negative file may pay off their returned checksquickly, and frequently will have money in their account to cover futureissued checks. When this type of account holder gets turned down for atransaction because they appear in the negative file, the retailer losesa sale and potentially creates a customer service issue, when, inreality, the retailer may have declined a valid form of payment and mayhave lost a sale unnecessarily.

SUMMARY OF THE INVENTION

Some embodiments of the invention provide a system for assigning a riskscore to a financial account. The system can include an accountinformation application that stores characteristics regarding thefinancial account, and a scoring application configured to obtain thecharacteristics, determine a risk score for the financial account, andstore the risk score and an identifier of the financial account in astorage location.

Additional embodiments of the invention provide a method of validating apayment. The method can include obtaining a first account identifier;accessing a database containing a plurality of risk scores, each one ofthe plurality of risk scores being associated with one of a plurality ofaccount identifiers; obtaining a first risk score from the plurality ofrisk scores, the first risk score being associated with the firstaccount identifier; and determining an acceptance decision by comparingthe first risk score against a risk threshold value.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for determining a risk score for a financialaccount according to one embodiment of the invention.

FIG. 2 is a flow chart illustrating a process of determining a riskscore for a financial account according to one embodiment of theinvention.

FIG. 3 is a decision tree for applying a risk score to a financialaccount according to one embodiment of the invention.

FIG. 4 is a system for validating a payment by evaluating the risk scoreassociated with the payment according to one embodiment of theinvention.

FIG. 5 is a flow chart illustrating a process of validating a payment byevaluating the risk score associated with the payment according to oneembodiment of the invention.

FIG. 6 is a flow chart illustrating a process of adjusting a riskthreshold value according to one embodiment of the invention.

DETAILED DESCRIPTION

Before any embodiments of the invention are explained in detail, it isto be understood that the invention is not limited in its application tothe details of construction and the arrangement of components set forthin the following description or illustrated in the following drawings.The invention is capable of other embodiments and of being practiced orof being carried out in various ways. Also, it is to be understood thatthe phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limited. The use of“including,” “comprising” or “having” and variations thereof herein ismeant to encompass the items listed thereafter and equivalents thereofas well as additional items. The terms “mounted,” “connected” and“coupled” are used broadly and encompass both direct and indirectmounting, connecting and coupling. Further, “connected” and “coupled”are not restricted to physical or mechanical connections or couplings,and can include electrical connections or couplings, whether direct orindirect.

In addition, it should be understood that embodiments of the inventioninclude both hardware and electronic components or modules that, forpurposes of discussion, may be illustrated and described as if themajority of the components were implemented solely in hardware. However,one of ordinary skill in the art, and based on a reading of thisdetailed description, would recognize that, in at least one embodiment,the electronic based aspects of the invention may be implemented insoftware. As such, it should be noted that a plurality of hardware andsoftware based devices, as well as a plurality of different structuralcomponents may be utilized to implement the invention. Furthermore, andas described in subsequent paragraphs, the specific configurationsillustrated in the drawings are intended to exemplify embodiments of theinvention and that other alternative configurations are possible.

FIG. 1 illustrates a scoring system 10 according to one embodiment ofthe invention. The scoring system 10 can be configured to assign a riskscore to a financial account of an account holder. The scoring system 10can include an account information application 12, a scoring application14, and a scored negative file 16. The account information applicationcan be an application configured to provide information regarding afinancial account. The account information application 12 can beexecuted by a computer, database, server, etc., and can be operated ormanaged by a bank, credit union, or other institution capable of issuingand maintaining financial accounts. A retail computer, such as a cashregister or point-of-sale (“POS”) terminal, can also execute the accountinformation application 12.

The account information application 12 can generate messages whenactivity occurs on a financial account. For example, the accountinformation application 12 can transmit characteristics of the financialaccount to the scoring application 14 when a new account is opened atthe financial institution, when a deposit or withdrawal is made on thefinancial account, when a check for the financial account successfullyclears, when a check for the financial account gets returned forinsufficient funds, etc. The account information application 12 cantransmit characteristics to the scoring application 14 over a directlink or indirectly through any suitable network, such as a local areanetwork (“LAN”) or the Internet. The characteristics can also bemanually delivered to the scoring application 14.

Although FIG. 1 illustrates a direct connection between the accountinformation application 12 and the scoring application 14, otherintermediary devices and applications can be positioned between theaccount information application 12 and the scoring application 14, suchas various routers, gateways, and other transmitting and processingapplications. The intermediary applications can perform simpleforwarding or routing functionality or can process the transmitted data.An adapter application, for example, can obtain data from the accountinformation application 12 and can convert or translate the obtaineddata into a format or structure that is understood by the scoringapplication 14. Data transmitted by the account information application12 can include confidential information, such as financial accountnumbers, social security numbers, account holder names, etc. As aresult, the account information application 12, or an intermediaryprocessing application, can encrypt the transmitted data to keepconfidential and sensitive data secure.

The scoring application 14 can be executed by a retail or financialinstitution computer, server, database, etc., and can be configured toobtain data from the account information application 12. Although onlyone account information application 12 is illustrated in FIG. 1, thescoring application 14 can be configured to obtain data from a number ofaccount information applications 12 or other applications capable oftransmitting account data. The scoring application 14 can be part of theshared check authorization network (“SCAN”) and can serve as a centralprocessing location for a number of financial institutions.

The scoring application 14 can be configured to assign a risk score to afinancial account. After the scoring application 14 determines a riskscore, the scoring application 14 can be configured to transmit the riskscore to the scored negative file 16. The scoring application 14 cantransmit a financial account identifier associated with each risk score.The financial account identifier can be a checking account number, acheck card number, a driver's license number, a personally-chosenidentifier, etc. The scored negative file 16 can also include otherinformation, such as the number of checks returned for insufficientfunds, the date of last deposit, the date of the last returned check,the amount of the last deposit, the number of checks awaitingprocessing, etc. The scoring application 14 can be configured totransmit all of the data received regarding a financial account to thescored negative file 16. However, in some embodiments, the scorednegative file 16 can include only the risk score and an accountidentifier for each financial account. The data used to arrive at therisk score, such as the data received from the account informationapplication 12, can be stored in a separate archive or storage location(not shown).

The scored negative file 16 can be stored in a database or other datastorage device. The scored negative file 16 can also be printed by animage processing apparatus, such as a printer, and physically stored orfiled by the retailer. As noted, a number of intermediary devices and/orapplications can be positioned between the scoring application 14 andthe scoring negative file 16. For example, the scoring application 14can transmit account data and the associated risk score to a datamanager application (not shown) that adds the data to a database orwrites a modified file to a disk. A data manager application can also beused to authenticate submitting devices, such as the scoring application14, before data is added to or modified in the database or the file.

In some embodiments, the scoring application 14 or other intermediaryapplication can encrypt the data before storing the scored negative file16 in a database or a file. Encrypting the data can allow onlyauthenticated applications to access or view data contained within thescored negative file 16.

FIG. 2 illustrates a process of assigning a risk score to a financialaccount according to one embodiment of the invention. The process can beexecuted by the scoring system 10 as described in FIG. 1, although othersystem configurations are possible. The account information application12 can obtain (at 20) information regarding a financial account. Theaccount information application 12 can access other applications orsystems in order to obtain the financial account information. Forexample, the account information application 12 can access bankingsystems or archives to obtain information regarding a particularfinancial account. Other devices and applications can be configured totransmit financial account information to the account informationapplication 12. The financial account information can be internally heldby the account information application 12. The account informationapplication 12 can be configured to obtain or calculate supplementaldata based on the information obtained or maintained for a financialaccount.

After the account information application 12 has obtained the financialaccount information, the account information application 12 can transmit(at 22) the information to the scoring application 14. However, thescoring application 14 can alternatively directly obtain the financialaccount information by accessing a data storage location of the accountinformation application 12. The scoring application 14 can also beconfigured to receive information from a number of account informationapplications 12 and combine all the information related to a particularfinancial account. The scoring application 14 can be configured toprocess the received information. The scoring application 14 can processthe received information by structuring the data into a particularformat or by validating the received data and issuing errors or messagesif the received information is incomplete or inaccurate.

After the scoring application 14 has obtained the financial accountinformation, the scoring application 14 can determine (at 24) a riskscore for the financial account. Various decision and predictiveapplications can be used to determine the risk score. In someembodiments, the scoring application 14 can use a decision tree todetermine the risk score for a financial account.

The scoring application 14 can store (at 28) the risk score along withan account identifier in the scored negative file 16. The scoringapplication 14 can store all of the risk scores and associated accountidentifiers in the scored negative file 16 or can only store a subset ofrisk scores and account identifiers. For example, in some embodiments,the scoring application 14 can only store risk scores for those accountsassigned a risk score over a certain value. In some embodiments, thescoring application 14 only receives account data for delinquentaccounts from the account information application 12, in which case onlythose financial accounts with a delinquent risk score are stored in thescored negative file 16. The delinquent risk score can be a high valueor a low value, depending on the particular calculations made and theparticular threshold values.

The risk scores for the financial accounts can be updated when necessaryso that the scored negative file 16 accurately indicates the currentrisk of a check being returned from the financial account. After aninitial risk score has been stored in the scored negative file 16, theaccount information application 12 can determine (at 30) whether anyinformation or characteristic associated with the particular financialaccount has been updated or modified. When the information orcharacteristics of a financial account are updated or modified, a newrisk score can be calculated and stored so that the current riskassociated with the financial account is accurately indicated in thescored negative file 16. For example, a deposit into a financial accountmay result in a new risk score indicating less risk associated with thefinancial account. The new risk score can allow the account holder touse a check as a form of payment, even if the old score would havecaused a retailer to reject a check from the account holder. It is inthe best interest of both retailers and account holders to have riskscores recalculated when a financial account experiences activity.

If an event has occurred warranting the recalculation of the risk score,the account information application 12 can obtain (at 20) updated ormodified financial account information for the financial account. Theaccount information application 12 can transmit (at 22) the updated ormodified account information to the scoring application 14, and thescoring application 14 can determine (at 24) and store (at 28) a newrisk value. New risk scores may overwrite existing risk scores or may bestored as a history of risk scores (e.g., kept over time and associatedwith particular dates).

Events warranting the recalculation of the risk scores include, but arenot limited to, the return of an unfinanced check for the financialaccount, the clearing of a financed check for the financial account, theobserving of no or little activity on the financial account over acertain number of days, or the elapsing of a certain number of dayswithout payment on a returned check. In the absence of account activityor events, the account information application 12 can continue to waitfor information to be added or modified.

In some embodiments, the scoring application 14 can be configured toquery the account information application 12 for updated accountinformation. For example, the scoring application 14 can be configuredto periodically cycle through a list of known financial accounts andrequest a status check from the account information application 12. Inone embodiment, the scoring application 14 can request accountinformation each day from the account information application 12 for allaccounts listed in the scored negative file 16. Similarly, the accountinformation application 12 can be configured to periodically sendaccount information to the scoring application 14, regardless of whetherthe account information has been modified since the previous time thescoring application 14 received the account information. In otherembodiments, the addition or modification of account information cantrigger the transmitting of the new account information to the scoringapplication 14 without the account information application 12 or scoringapplication 14 querying or waiting for updates or requests.

FIG. 3 illustrates a decision tree 40 for use with the scoring system 10in some embodiments of the invention. The scoring application 14 can usethe decision tree 40 to determine a risk score for a financial account.The decision tree 40 can use as an input an object described by a set ofattributes or characteristics and can return a predicated output valuefor the input. The decision tree 40 reaches an output by performing asequence of tests at a series of internal nodes. Each internal node inthe decision tree 40 corresponds to a test of the value of one or moreof the attributes or characteristics. The decision tree 40 illustratedin FIG. 3 includes a number of internal nodes that test variousfinancial account characteristics, such as the number of open or unpaidpayments (“# Open”), the number of paid or financed payments (“# Paid”),the maximum number of days a payment has been unpaid (“Days Open”), thenumber of days the most recent unpaid payment has remained unpaid (“DaysSince Last Open”), the highest number or identifier for an issuedpayment (“Max Check #), etc.

The branches from the nodes correspond to the possible results of thetest. Each branch may indicate a single test result or may specify arange of possible results. The branches illustrated in FIG. 4 arelabeled with a range of possible values. Some of the branch labels havebeen omitted to aid the clarity and readability of the figure. Thebranches lead to other internal nodes or to leaf nodes. Each leaf nodein the decision tree 40 marks a final decision and specifies the valueto be returned, or the output, if that leaf node is reached.

When used by the scoring application 14, the input to the decision tree40 can include attributes or characteristics of a financial account. Theattributes or characteristics can include the number of paid or clearedchecks, the number of returned or unfinanced checks, the days the firstreturned check has remained unfinanced, the date of the last clearedcheck, the average number of days returned checks remain unfinanced, thedate and time when the last risk score was calculated, etc. The scoringapplication 14 can obtain the attribute or characteristics from theaccount information application 12, can calculate any corresponding datainternally, or can internally store the information. For example, thescoring application 14 can receive the dates of all paid and returnedchecks and can calculate the average number of days that returned checksremain unfinanced. In other embodiments, the scoring application 14 canreceive all the data required directly from the account informationapplication 12 or another input device or application, without having toperform any calculations. In some embodiments, the scoring application14 can internally store and access a portion of the attribute orcharacteristic information, such as the date of the last the risk scorecalculation. This information can be stored in the scored negative file16 or another associated archive.

The decision tree 40 shown in FIG. 3 includes a root node 42 thatrepresents the starting location of the decision tree 40. Upon receivingaccount information for a financial account, the scoring application 14can input the account information into the decision tree 40 starting atthe root node 42. At the root node 42, the decision tree 40 can examinethe number of open or returned checks for the financial account. Fourbranches leading to other nodes extend from the root node 42, creatingfour possible results or outcomes for the test presented at the rootnode 42. Each branch is marked with an option for the open or returnedcheck count. For example, the top branch leading from the root node 42is followed if the financial account has 1 to 2 returned checks, thesecond branch is followed if the account has 2 to 3 returned checks, thethird branch is followed if the account has 3 to 4 returned checks, andthe fourth or bottom branch is followed if the account has 4 to 76returned checks. The ranges assigned to any of the branches and/or nodesdescribed herein are provided as example ranges only. Various otherranges than those shown and described can be assigned.

If, for example, a financial account has 5 open or returned checks, thebottom branch can be followed from the root node 42 to node 44. At node44, the number of paid or cleared checks associated with the financialaccount is determined. Node 44 has two branches leading from it. The topbranch is followed for accounts having 0 to 9 paid checks, while thebottom branch is followed for accounts having 9 to 121 paid checks. Ifthe financial account has 10 paid checks (or another number within therange from 9 to 121), the bottom branch is followed to a leaf node 46.The leaf node 46 represents a final decision of the decision tree 40,because no additional paths are available. The leaf node boxes shown inFIG. 3 include numbers, with each number representing a risk score. Insome embodiments, other markers or identifiers can be used to specify arisk score. For example, financial account risk scores can be anumerical value, a character string, a binary string, a graphicalpattern, or any combination thereof.

In one embodiment, the decision tree 40 has thirty leaf nodesrepresenting thirty possible risk scores. Leaf node 46 is marked withthe number 25 indicating that the financial account whose attributeslead to leaf node 46 in the decision tree 40 has been assigned a riskscore of 25. In the example presented above, a financial account with 5open or returned checks and 10 paid or cleared checks would be assigneda risk score of 25. If, however, the financial account had 5 open orreturned checks and had 7 paid checks, the top branch would be followedto a leaf node 48 where the financial account would be assigned a riskscore of 30.

In some embodiments, the higher the risk score, the higher the risk thatan account holder will write an unfinanced bad check. From the aboveexample, a risk score of 30 can be associated with more risk score than25, because accounts with the same number of returned checks, but fewerpaid checks, can pose a higher risk of repeated unfinanced checkwriting. Alternatively, a risk score scale can be generated in such away that the lower the risk score, the higher the risk that an accountholder will write an unfinanced check.

The effectiveness of the decision tree 40 can be evaluated and modifiedin some embodiments of the invention. The risk scores assigned by thedecision tree 40 can be reviewed to ensure that accurate scores arebeing determined for financial accounts and that a financial account isnot receiving too high of a risk score or too low of a risk score. Anunnecessarily high risk score can prohibit an account holder frompresenting a payment for a transaction, and an inaccurately low riskscore can allow an unfinanced payment for a transaction to be acceptedby a retailer. The decision tree 40 can be modified by changing theranges specified on the branches and the score values placed at the leafnode. New tests can also be added to the decision tree 40 such as thedifference between the first check number and the most recent checknumber, the date of the last deposit, etc.

FIG. 4 illustrates a validating system 60 according to one embodiment ofthe invention. The validating system 60 can be configured to validate orauthorize an account holder presenting a check for payment. Thevalidating system 60 can include a payment processing application 62, apayment validation application 64, and a scored negative file 66. A POSterminal or a cash register can execute the payment processingapplication 62. In other embodiments, another suitable hardware orsoftware apparatus can be configured to obtain financial account dataduring a transaction. The payment processing application 62 can also beexecuted by a retail clerk or cashier.

Data obtained by the payment processing application 62 can be sent tothe payment validation application 64. The payment processingapplication 62 and payment validation application 64 can communicateover direct links or over a network such as the Internet. Multipleintermediary devices can also be connected between the paymentprocessing application 62 and the payment validation application 64.

In some embodiments, a POS terminal, cash register, or other suitabledevice, can execute the payment validation application 64. The paymentvalidation application 64 can be executed on the same device orapparatus as the payment processing application 62. In some embodiments,the functionality of the payment processing application 62 and thepayment validation application 64 can be combined and executed as asingle application. In some embodiments, the payment validationapplication 64 can be executed by a central payment validating computer,server, database, etc. The payment validation application 64 can beconfigured to determine an acceptance decision for payments presented byan account holder. The acceptance decision can specify whether thepayment should be accepted or declined. The acceptance decision can bebased on whether the financial account associated with the paymentmatches a financial account (or a financial account identifier) listedin the scored negative file 66. In some embodiments, the acceptancedecision can be based on a risk score associated with the financialaccount and a risk threshold value, in addition to the fact that thefinancial account is listed in the scored negative file 66.

In some embodiments, each retailer can individually set a risk thresholdvalue to establish an acceptable risk limit for payment processing. Therisk threshold value can provide a limit on risk scores that will beaccepted by a retailer or a transaction provider. Financial accountslisted in the scored negative file 66 can still be accepted by aretailer, if the financial account has a risk score within apredetermined amount of the risk threshold value. The predeterminedamount can accommodate situations in which the risk score is equal tothe risk threshold value or less than or greater than the risk thresholdvalue by a particular amount. The predetermined amounts can specify thatpayments from accounts with risk scores less than the risk thresholdvalue will be accepted, that payments from accounts with risk scoresequal to the risk threshold value will be accepted, that payments fromaccounts with risk scores greater than the risk threshold value will beaccepted, that payments from accounts with risk scores within a certainnumber of points of the risk threshold value will be accepted, or anycombination thereof.

In some embodiments of the invention, each retailer can set anindividual risk threshold value to establish a suitable balance betweenrejecting all payments and accepting all payments. Accepting allpayments can lead to lost sales through returned checks, but canincrease total sales by accepting checks that are ultimately financedfrom the financial accounts listed in the scored negative file 16.Alternatively, rejecting all payments linked to financial accountslisted in the scored negative file 16 can result in lost sales if anaccount holder does not have alternate payment methods, but can increasetotal sales by decreasing the amount of lost revenue due to returnedchecks. A retailer who cannot afford a large number of returned checksor who is currently experiencing a large number of returned checks andlosing revenue, can set a high risk threshold value (e.g., only thosefinancial accounts with a low risk will be accepted). Alternatively, aretailer can set a low risk threshold value (e.g., those financialaccounts with low and high risks will be accepted) hoping that theincrease in total sales by accepting more payments will be greater thanthe amount of sales lost by accepting checks that are later returned.

In some embodiments, the risk threshold value can be a dynamic valuethat is easily changed by each retailer or that changes automaticallybased on information regarding sales and/or previous returned checks. Inother embodiments, the risk threshold value can be set by the retailerassociated with the payment processing application 62, can be a standardvalue accepted by all retailers, or can be a specific risk thresholdvalue for a particular market. For example, a grocery store may be ableto set its own risk threshold value, may be required to adopt a riskthreshold value used by all retailers, or may be required to adopt arisk threshold value used by all grocery-related retailers.

In some embodiments, a payment validation application 64 can beindividually configured for a particular retailer. Multiple retailerscan also share one payment validation application 64. For example, thepayment validation application 64 can be managed by SCAN and can be usedby a number of payment processing applications 62. In other embodiments,retailers can have individually-configured payment validationapplications that transmit payment validation requests to a global orcentral payment validation application configured to provide paymentvalidation information to a number of retailers.

In some embodiments, the payment validation application 64 uses thescored negative file 66 to determine an acceptance decision. The scorednegative file 66 illustrated in FIG. 4 can be the same scored negativefile 16 illustrated in FIG. 2 or can be an individually-tailored scorednegative file 66 for the payment validation application 64. In otherembodiments, the scored negative file 66 can be a subset of the scorednegative file 16 based on a particular risk threshold value. Forexample, the scored negative file 66 can include a subset of financialaccounts listed in the scored negative file 16 whose risk scores areabove, below, or equal to the particular risk threshold value. Thescored negative file 66 can further be specialized to include onlyfinancial accounts having other particular attributes orcharacteristics, such as only those financial accounts having returnedchecks within a particular market. In some embodiments, the paymentvalidation application 64 can receive the scored negative file 66 from asecond payment validation application (not shown) configured to receiverisk threshold values, configured to access the stored scored negativefile 16, and configured to generate a list of financial accountsappearing in the scored negative file 16 that are above, below, or at aparticular risk threshold value. The payment validation application 64can also access the scored negative file 16 directly to generate theindividually-tailored scored negative file 66.

The scored negative file 66 can be stored locally in a data storagelocation managed by the payment validating application 64 or can bestored in a centrally-located storage location such as a database,server, etc.

Rather than using the scored negative file 66 with the subset offinancial accounts, the payment validation application 64 can beconfigured to use the entire scored negative file 16. The paymentvalidation application 64 can first determine whether the financialaccount in question is listed in the scored negative file 16, and thencan determine whether the financial account has a risk score that variesfrom the risk threshold value.

After determining whether a payment is associated with a financialaccount listed in the scored negative file 66, the payment validationapplication 64 can be further configured to report back to the paymentprocessing application 62 in order to indicate whether the payment isaccepted or declined.

FIG. 5 is a flow chart illustrating a process of validating a paymentpresented by an account holder for a transaction according to oneembodiment of the invention. In some embodiments, the components of thevalidating system 60, as illustrated in FIG. 4, are configured toexecute the steps of the process illustrated in FIG. 5. The paymentprocessing application 62 can obtain (at 70) a financial accountidentifier from an account holder. The payment processing application 62can obtain the financial account identifier by obtaining informationfrom a form of payment or a form of identification presented to thepayment processing application 62, such as a check card, a driver'slicense, a paper check, etc. The payment processing application 62 canobtain the information by scanning or reading the presented form ofpayment or identification. Alternatively, a retail clerk or cashier canrequest or read the information and can enter the information into thepayment processing application 62. Otherwise, the account holderpresenting the payment can enter the information into the paymentprocessing application 62 him or herself.

After obtaining the financial account identifier, the payment processingapplication 62 can transmit (at 72) the financial account identifier tothe payment validation application 64. The payment validationapplication 64 can use the account identifier to search the scorednegative file 66 to determine (at 74) whether the financial accountassociated with the payment currently being processed is listed in thescored negative file 66. In some situations, the account identifierprovided by the payment processing application 62 may identify more thanone financial account. For example, a driver's license number canidentify a number of financial accounts associated with a singleindividual or organization. The payment validation application 64 cansearch the scored negative file 66 for any financial account linked tothe account identifier, regardless of the particular financial accountthe current payment is originating from. An individual or organizationhaving a high risk score on one financial account can be at a higherrisk for returned checks on any account he or she owns, and thus, allpayments from this individual or organization can be declined.

Alternatively, the payment validation application 64 can transmit theaccount identifier to a second payment validation application (notshown). The second payment validation application can return a riskscore from the scored negative file 16. The second payment validationapplication can allow the first payment validation application 64 todetermine whether the risk score is above or below the risk thresholdvalue. In some embodiments, the second payment validation applicationcan make the acceptance decision for the payment validation application64. For example, the second payment validation application can instructthe first payment validation application 64 to either accept or deny thepayment by returning an acceptance decision. The second paymentvalidation application can determine the acceptance decision bycomparing the risk score for the financial account to the risk thresholdvalue.

If the account identifier is associated with more than one financialaccount, the secondary payment validation application can return morethan one risk score or can return only one of the multiple risk scores.For example, the secondary payment validation application can determinean acceptance decision based on the highest risk score or can return thehighest risk score to the payment validation application 64.

If the account identified by the account identifier is listed in thescored negative file 66 or if the risk score is greater than the riskthreshold value, the payment validation application 64 can decline (at76) the payment. Alternatively, if the financial account is not listedin the scored negative file 66 or if the risk score is less than therisk threshold value, the payment validation application 64 can accept(at 78) the payment. Regardless of whether the payment validationapplication 64 accepts or declines the payment, the payment validationapplication 64 can be configured to record (at 80) the decision.Recording the decision can include storing information regarding thetype of payment that was presented, the transaction the payment waspresented for, and/or whether the payment was accepted or declined.Recorded data can be stored locally by the payment validationapplication 64, by the payment processing application 62, or by otherapplications managed by the retailer. Otherwise, recorded data can betracked and stored at a data storage location located external to thevarious applications managed by the retailer. A payment authorizationapplication can be configured to track decisions for a number ofretailers. Recording the payments accepted and the payments declined,along with their associated transactions, allows retailers to tracktheir individual risk threshold value, and allows retailers to adjusttheir individual risk threshold value, as will be described below.

FIG. 6 is a flow chart illustrating a process of adjusting a riskthreshold value according to one embodiment of the invention. After aretailer individually sets a risk threshold value, the retailer cantrack payment acceptance decisions and can adjust the risk thresholdvalue based on previous decisions and their outcomes. Referring to FIG.6, a retailer can set (at 90) a risk threshold value. A retailer can setthe risk threshold value by inputting the selected value into a computeror other application such as the payment validation application 64. Aretailer can also set a risk threshold value by manually informing acentral payment authorization application or organization of a desiredrisk threshold value. For example, a retailer can call a paymentauthorization application or organization and voice the desired riskthreshold value. The payment authorization application can record therisk threshold value and can generate the scored negative file 66 forthe payment validation application 64 of the retailer based on theretailer's individual risk threshold value.

Once the risk threshold value has been set, the retailer can process (at92) payments as shown and described with respect to FIG. 5. With eachpayment processed, a record can be recorded to an internal or remotedata storage location as previously described with respect to FIG. 5.The record can include the financial account identifier, the paymentissued, the characteristics of the transaction, the acceptance decision,etc.

The retailer, in some embodiments, can view (at 94) historical data forprocessed payments. The retailer can internally store the information orcan request the historical data from a remote storage location. Thepayment validation application 64 can be configured to obtain andprocess the historical data, although the retailer can use otherapplications to track payment processing.

The historical data can be presented to the retailer in a number offorms, such as, graphical or chart form, summary form, raw data from,etc. The historical data can indicate sales lost due to declinedpayments, revenue lost due to the acceptance of unfinanced payments,etc. The retailer can use the historical data to determine whether therisk threshold value is creating an acceptable balance between lostsales and lost revenue. The retailer can determine (at 96) whether toadjust the risk threshold value based on past payment processing. If theretailer has accepted a number of unfinanced payments that resulted inlost revenue, the retailer can raise the risk threshold value so thatonly checks from low-risk-score accounts are accepted. Alternatively, ifthe retailer has experienced a drop in sales and an increase in declinedpayments, the retailer can reduce the risk threshold value to acceptmore checks from high-risk-score accounts in an effort to increasesales. The retailer can keep the risk threshold value constant if theretailer feels that the risk threshold value is properly discriminatingbetween high-risk-score accounts and low-risk-score accounts.

If the retailer decides to modify the risk threshold value, the retailercan set (at 90) the threshold value to a new value and can begin toprocess (at 92) payments using the new risk threshold value. If theretailer does not modify the risk threshold value, the retailer returnsto processing (at 92) payments. In some embodiments, the retailer canadjust the risk threshold value at any time and as many times aswarranted.

Other devices and applications in addition retailer or transactionprovider applications and devices can access the scored negative files16 and 66 to determine the financial stability of an account holder. Forexample, a credit card or credit issuing organization can use the scorednegative files 16 or 66 to determine whether an account holder has beendiligent in writing financed checks and can adjust a credit limit basedon the risk score assigned to the account holder.

Although embodiments of the invention are described with respect tochecking accounts, embodiments of the invention are not limited tospecific types of financial accounts. Credit card accounts, savingsaccounts, and other financial accounts, for example, can utilizeembodiments of the invention as described above. Checking accounts areused for illustrative purposes because negative files are traditionallyused to validation check payments. It should also be understood thatreference to “writing a check” or other similar phrases can include notonly the physical writing of a check, but also using a debit card tomake a point-of-sale purchase or to alter the financial account in anymanner (such as by making an ATM withdrawal).

Various features and advantages of the invention are set forth in thefollowing claims.

1.-13. (canceled)
 14. A method of adjusting a risk score for a financialaccount, the method comprising: obtaining a plurality of characteristicsregarding the financial account; applying the plurality ofcharacteristics to a decision tree to determine a first risk score;storing the risk score and an identifier for the financial account in astorage location; reviewing the plurality of characteristics when atleast one of the plurality of characteristics changes; re-applying theplurality of characteristics to the decision tree to determine a secondrisk score; and updating the first risk score with the second riskscore.
 15. The method as claimed in claim 14, wherein the plurality ofcharacteristics includes a number of returned payments.
 16. The methodas claimed in claim 14, wherein the plurality of characteristicsincludes a number of cleared payments.
 17. The method as claimed inclaim 14, wherein the plurality of characteristics includes an accountbalance.
 18. The method as claimed in claim 14, wherein the plurality ofcharacteristics includes a date of last activity.
 19. The method asclaimed in claim 14, wherein the plurality of characteristics includes atime duration for a returned payment.
 20. The method as claimed in claim14, and further comprising assigning one of thirty possible risk scores.21. A method of adjusting a risk threshold value for the acceptance ofunfinanced payments, the method comprising: choosing a risk thresholdvalue; receiving a plurality of payments; obtaining a risk score foreach one of the plurality of payments; determining an acceptancedecision for each one of the plurality of payments by comparing the riskscore for each one of the plurality of payments against the riskthreshold value; and adjusting the risk threshold value in order toadjust the risk level for the acceptance of unfinanced payments.
 22. Themethod as claimed in claim 21, further comprising accepting a firstquantity of the plurality of payments in which the risk score is lessthan the risk threshold value.
 23. The method as claimed in claim 21,further comprising recording the acceptance decision for each one of theplurality of payments.
 24. The method as claimed in claim 22, furthercomprising declining a second quantity of the plurality of payments inwhich the risk score is greater than the risk threshold value.
 25. Themethod as claimed in claim 24, further comprising recording a thirdquantity of payments that are unfinanced.
 26. The method as claimed inclaim 25, wherein adjusting the risk threshold value in order to adjustthe risk level for the acceptance of unfinanced payments includesevaluating the first quantity of payments, the second quantity ofpayments, and the third quantity of payments.
 27. A system for assigninga risk score to a financial account, the system comprising: an accountinformation application configured to store characteristics regardingthe financial account; and a scoring application configured to obtainthe characteristics, determine a risk score for the financial account,and store the risk score and an identifier of the financial account in astorage location.
 28. The system as claimed in claim 27, wherein thescoring application is further configured to request characteristicsregarding the financial account from the account informationapplication.
 29. The system as claimed in claim 27, wherein the accountinformation application is further configured to transmit thecharacteristics to the scoring application.
 30. The system as claimed inclaim 27, wherein the scoring application is further configured to storethe characteristics in the storage location. 31-46. (canceled)
 47. Acomputer readable medium containing instructions for adjusting a riskthreshold value, the instructions comprising: setting a first riskthreshold value; obtaining a plurality of financial account identifiersfor a plurality of payments associated with a plurality of transactions;obtaining a risk score for each of the plurality of financial accountidentifiers; determining an acceptance decision for each risk score bycomparing each risk score against the first risk threshold value;recording each acceptance decision and each associated transaction;evaluating the acceptance decisions and the associated transactions; andsetting a second risk threshold value based on the accepted decisionsand the associated transactions.
 48. The computer readable medium asclaimed in claim 47, further comprising instructions for recording aplurality of transactions associated with unfinanced payments.
 49. Ascored negative file configured to provide information regarding theactivity of a financial account in order to validate a payment, the filecomprising: a plurality of financial account identifiers, wherein eachfinancial account identifier includes a risk score specifying apredicted level of risk that an unfinanced payment will result for aparticular financial account.
 50. The scored negative file as claimed inclaim 49, further comprising a plurality of characteristics for each oneof the plurality of financial account identifiers.
 51. The scorednegative file as claimed in claim 50, wherein the plurality ofcharacteristics define financial account activity.
 52. The scorednegative file as claimed in claim 50, wherein the characteristics areused to generate the risk score.